A Proof Obligation Generator for VDM - SLBernhard

proof obligations errors, warnings proof obligations parser errors, warnings syntax tree type checker proof tool GUI Fig. 1. Interaction of the new type checker. The main advantage of this approach is the combination of a type checker and a proof tool. In the cases where the type checker is not able to check the consistency, the proof theory in the proof tool can be applied to prove the consistency. The link between the two components are the generated proof obligations. Minor simpli cations and proofs of trivial proof obligations could be made directly by the POG. However, in the present approach the decision has been made to forward these tasks to the proof tool, which is designed for these purposes. 3.1 Proof Obligations A proof obligation for type consistency is a statement that must be proved in order to ensure type consistency. Therefore, the POG is a conditional type checker which returns true under the assumption that the POs generated during the type check can be proved. This process is called conditional type checking. In order to be able to prove POs, they contain context information. The general form of a proof obligation is that of a proof rule, where the assumptions are generated out of the context and the conclusion is the property that must hold. Thus, the general form of a PO is context information predicate In the examples below, the proof obligations will be given in an ASCII representation which is: PO: context information ==> predicate A proof obligation is modelled as a proof (inference) rule consisting of a list of hypotheses and a conclusion. The rule states that the conclusion holds whenever the hypotheses hold [6, 20]. The abstract syntax for a proof rule is: PrfRule : :hyp : Sequent con :AllExpr ; To be compatible with the proof theory a hypothesis is de ned as a sequent P ` R. Its meaning is that the local conclusion R is derivable from the local assumptions P in a subproof. Formally, a sequent is composed of local variables, a sequence of local assumptions, and a local conclusion: Sequent : : vars :Name lhyp :AllExpr lcon :AllExpr ; However, it turned out that for formulating the proof obligations the use of local assumptions is not needed. Therefore, the hypotheses are sequents without local assumptions (` R). In the following, we skip the turnstile in the hypotheses, when we present a proof obligation. AllExpr is a syntactic extension of VDM-SL expressions with type judgements (e.g., 3 :N). This extension is necessary in order to reason over types. AllExpr = Expr j TypeJudgement ; TypeJudgement : : expr : Expr type :TypeRep 3.2 Context Generation Context information forms the hypothesis of a proof obligation. Therefore, the existing speci cation of the type checker has been extended in order to generate the context. The context of a certain location in a speci cation is the summation of logical conditions that must hold in order to reach this location during evaluation. The following example illustrates the notion of context: if is-nat(x) then x + 1 else 1 To reach x + 1 during the evaluation, the condition is-nat(x) must be true. Therefore, the context of x + 1 is is-nat(x). Obviously, the context of 1 in the else branch is not is-nat(x). For generating proof obligations we distinguish between two kinds of context: Type judgements of the form identi er :Type are used to record membership of a type.This may be read as \identi er is of type Type". They are provided as context information to infer over types in the typed logic of partial functions and to provide the proof tool with the needed type information. The type information is stored in the environment of the type checker. Boolean expressions like is-nat(x) in our example above are stored in a context stack, while performing the consistency check. When checking the then-branch of an if-expression the test expression (above: is-nat(x)) is pushed onto the stack. Checking the else branch, we rst remove the test expression from the stack (pop), then the negated test expression (above: not is-nat(x)) is pushed onto the stack. 4 Proof Obligations for Expressions and Functions When type checking VDM-SL expressions, two categories of consistency checks can be distinguished: (1) Type compatibility and (2) domain checking, which checks whether functions and operators are applied to their de ned domains. Both may be undecidable. The rst because of union and subtypes, the second because of partial operators and functions with pre-conditions. In addition to these two categories the new POG also generates satis ability obligations for implicitly de ned functions and operations [21]. 4.1 Type Compatibility A compatibility check fails if the actual type and an expected type are overlapping, but the rst is not a subtype of the second. This undecidable case occurs if the actual type is a union type or if the expected type is a subtype of the actual type. Consider the function f, which increases its argument if it is a natural number, otherwise 1 is returned. f: bool | nat -> N1 f(x) == if is-nat(x) then x + 1 else 1 The returned value is restricted by an invariant to the natural numbers unequal to zero: N1 = nat inv n == n <> 0. The function is consistent, which means it will not cause a run-time error. However, the existing type checker fails to accept it, because: (1) the plus operator in x + 1 expects numeric types and therefore x must be compatible to (here: a subtype of) real. However, the actual type of x is the union type bool | nat which only overlaps the type real, but is not a subtype of it. (2) To check the consistency of the return value the type checker would have to statically determine, whether the invariant function is true or false, which is is not possible. Therefore the extended type checker raises two proof obligations stating the needed properties that in cases: (1) x is of type real and (2) the invariant holds: PO1: is-nat(x) ==> x:real PO2: x:bool | nat ==> inv-N1( if is-nat(x) then x + 1 else 1 ) PO1 trivially states that if x is a natural number then it is a real number. Note that this theorem is only valid for VDM-SL, with non-disjoint types. This PO can be proved automatically by the proof tool. PO2 states that for the function body the implicitly de ned invariant function for N1 holds. 4.2 Domain Checking For domain checking, proof obligations are generated for partial operators and for function applications if the function has a pre-condition. These POs ensure that the operands/parameters are in the de ned domain. Examples of partial operators are division, head and tail. A pre-condition in a function restricts the domain by an additional predicate. The use of such a function generates a proof obligation stating that the pre-condition function holds. Below the general POs for a / b and g(a), where g is de ned with a pre-condition, are given: PO1: context ==> b <> 0 PO2: context ==> pre-g(a) Below we illustrate how such domain checking is carried out for partial operators. Again, the well-formedness operation of a division expression serves as the demonstrating part of the speci cation to illustrate the changes made for the POG. To see the modi cations compare the following with the speci cation in Section 2.3: wf -NUMDIV -POG : (POS j DEF) BinaryExpr o ! B TypeRep wf -NUMDIV -POG (i ;mk-BinaryExpr (lhs; -; rhs)) 4 let mk(wf -lhs; lhstype) = wf -Expr (i ; lhs), mk(wf -rhs; rhstype) = wf -Expr (i ; rhs), ExpectedLhsAndRhsType = mk-BasicTypeRep (REAL) in let lhscomp = IsCompatible (i ; lhstype;ExpectedLhsAndRhsType), rhscomp = IsCompatible (i ; rhstype;ExpectedLhsAndRhsType) in (if : lhscomp then if i = DEF then GenPO(mk-TypeJudgement (lhs;ExpectedLhsAndRhsType)) else GenErr("Lhs of 0=0 is not a numeric type") ; if : rhscomp then if i = DEF then GenPO(mk-TypeJudgement (rhs;ExpectedLhsAndRhsType)) else GenErr("Rhs of 0=0 is not a numeric type") ; if i = DEF ^ rhstp 6= mk-REP `BasicTypeRep (NATONE) then GenPO(mk-BinaryExpr (rhs;NE;mk-RealLit (0); nil )) ; if i = DEF then return mk(wf -lhs ^ wf -rhs;ExpectedLhsAndRhsType) else return mk(wf -lhs ^wf -rhs ^ lhscomp ^ rhscomp; ExpectedLhsAndRhsType) ) The main di erence compared to the previous speci cation is the generation of proof obligations in DEF mode, instead of error messages: If the compatibility check is not successful a PO is generated (GenPO) stating that the expression (rhs or lhs) is of the expected type. This is done using a type judgement. For domain checking a PO stating that the right-hand side is not equal (NE) to zero is generated. In de nite mode only the well-formedness of the leftand righthand side is returned, because the compatibility and the domain constraint are assumed to be true. This assumption is veri ed later using the proof tool by proving the generated proof obligations. The operation GenPO takes the conclusion of the PO as an argument. During type checking the context is collected from the abstract syntax tree and is stored separately and updated in a context stack. This context together with the conclusion argument is used by GenPO to synthesise a proof obligation. 4.3 Satis ability Satis ability obligations state that it must be possible to nd a model for implicitly de ned constructs such that for all valid input a valid output must exist. The satis ability of an implicit function is thus another VDM-SL concept that is covered by the POG. Implicit functions are de ned by means of preand post-conditions. A post-condition is a truth valued expression which speci es what must hold after the function is evaluated. A post-condition can refer to the result identi er and the parameter values. Consider an implicit speci cation of the division: Div( a:real, b:real) r:real pre b <> 0 post a = r * b The pre-condition restricts the domain of div. The post-condition states a relation between the operands a, b and the result r. For an implicit function de nition to be consistent, there must exist a return value satisfying the post-condition when the pre-condition is satis ed. This property is called the satis ability of implicit functions. Below the satis ability PO for Div is given: PO: b <> 0 ==> exists r:real & a = r * b As in explicit functions the pre-condition is taken as the context. A similar strategy is used for implicitly de ned operations. 5 Pattern Matching Pattern matching is one of the advanced features of VDM-SL. All constructs containing patterns are powerful tools in specifying. However, patterns raise some di culties in type checking that are worth investigating. The use of patterns depends on the expressions containing them. In this section let and cases expressions will serve as the demonstrating example constructs. A pattern is a template for a value of a particular class of type. It is always used in a context where it is matched to a value of a certain type. Consider the set enumeration pattern fa, 2g. This pattern matches only set values with two elements, where one of the elements is 2. The identi er a is called a pattern identi er and matches any value, of any type. The match value 2 can only be matched against the value itself. Possible values matching the set enumeration pattern are f1, 2g or ftrue, 2g. A full description of all di erent kinds of patterns can be found in [12, 31]. In general, type checking patterns can be seen as checking if the patterns can match associated values. If they cannot, the speci cation has to be rejected. A pattern identi er, for example, is compatible to all types, but a set enumeration pattern expects a set type. This corresponds to type checking for possible consistency (POS mode). However, de nite consistency demands more advanced checks, which depend on the usage of patterns. In the following it will be demonstrated that these de nite checks are often statically undecidable and how the extended type checker overcomes this problem by generating proof obligations. 5.1 Let expressions In let expressions patterns are used to improve the readability of complicated expressions or to decompose complex structures. The general form of a simple let expression is let pattern = value in expr . We consider the following example in order to investigate the behaviour of the type checker: let fa,bg = if true then f1,2g else 0 in a + b In practice the example would be useless and of poor quality, because the else branch is in fact \dead code". However, the expression is consistent and serves to look into the edges of type checking pattern expressions. The expression evaluates to 3. The if expression is of the union type set of nat | nat. As explained, the set enumeration pattern matches only with set values. In possible mode the type checker checks if the pattern possibly matches the value, i.e. if the set of values the pattern denotes overlaps the values denoted by the expression. In the example above this is the case. To be de nite consistent the type checker has to guarantee the match. This is not possible, without evaluating the expression. A check of this kind is undecidable in general and therefore a proof obligation stating that the pattern matches the expression/value is needed. Using an existential quanti cation we are able to formulate a predicate \pattern matches value". The match proof obligation for the example above looks like: PO: exists a, b:nat & fa,bg = if true then f1,2g else 0 Verifying this PO ensures formally that the pattern matches the value. During the process of generating a proof obligation, the pattern fa,bg is turned into an expression. Note that for patterns containing a match value in any case a proof obligation has to be generated to ensure the de nite consistency. The following example makes this obvious: let fa,2g = f1,2g in a The let expression above evaluates to 1. The match value 2 restricts the matching property: The pattern matches only sets of two elements where 2 is one of the elements. This is not decidable in general. Therefore the PO PO: exists a:nat & fa,2g = f1,2g is generated. 5.2 Cases Expressions The use of patterns in cases expressions is very di erent from what was presented above. Cases expressions allow the choice of one from a number of expressions on the basis of the value of a particular expression. Consider the following cases expression: let a in set f1, 2, f1,0g, f2,0gg in cases a: 1, f1,bg -> DoThis(1), 2, f2g union b -> DoThat(2), others -> 0 end The possible values of a are de ned by a let be-such-that expression. Here patterns are used to de ne the branches of a cases expression. The expression which is going to be evaluated is selected by pattern matching, where several patterns can be used to de ne one branch. Cases expressions need special treatment in de nite type checking. The existing type checker had to be improved, because errors were returned in almost all cases. Type checking the example above produced several error messages \Pattern cannot match". However, the expression is in fact type consistent. The reason for the overly strict behaviour of the type checker was, like for let expressions above, that every pattern was checked for its well-formedness in de nite mode. However, the semantics of pattern matching used this way is di erent from that in let-expressions. Type checking a pattern in de nite mode assures that it will match de nitely. This approach is not feasible in a cases expression, where pattern matching serves to select, not to de ne a value. The patterns in the cases expression above have to be able to match to a, which means that the sets of values they denote must overlap the value domain of the expression a. Therefore, patterns in cases expressions only need to be possibly well-formed (consistent). If the possible well-formedness check fails for a pattern, this pattern can never match and the corresponding expression will become \dead code" (holds for a single pattern). Figure 2 shows the type relations for cases expressions. The grey areas indicate the set of values to which the patterns in the cases expression match. The white area (expr :a) is the set of values denoted by the type of a. The di erent possibilities for the pattern types are: (1) The pattern is overlapping expr : a (p1 to p3). (2) The pattern does not overlap expr :a (p4) and therefore cannot match. (3) The pattern is a subtype of expr :a (p5). (4) The type of expr :a is a subtype of the pattern. (5) A pattern identi er, which matches with every value, occurs. It covers the whole type universe of VDM-SL. (6) The others alternative is present. It covers the white area of the domain of expr :a, which is not covered (overlapped) by the alternative patterns. expr. a p1 p2 p3 p4 p5 Fig. 2. The sets of values which match the patterns in a cases expression. In VDM-SL the others alternative is not mandatory, if the expression to which the alternative patterns are matched (expr :a) is fully covered (overlapped) by these patterns. Thus, the others construct can be skipped, if one of the alternatives will match the expression de nitely. In the example above the others construct can be omitted, because the other alternatives fully cover the possible values. To ensure the coverage of the expression by the patterns in a cases expression without an others branch or a pattern identi er a proof obligation has to be generated. The coverage PO for the above cases expression without an others construct would be: PO: a in set f1, 2, f1,0g, f2,0gg ==> exists b: nat | set of nat & a in set f1,2g or f1,bg = a or f2g union b = a The proof obligation states that for all a in the set, a match must be possible. The match values are summarised in a value set. The provability of this proof obligation shows the de nite consistency of the example even without the others branch. 6 Operations In VDM-SL functionality can be de ned both by functions and operations. What separates operations from functions is the use of states (variables in traditional programming languages). Operations can manipulate local and global states and are therefore imperative. As functions they can be de ned both implicitly and explicitly. An explicit operation contains a sequence of statements which is very similar to statements found in ordinary programming languages. The main problem concerning our work is that no proof theory covering the full imperative part of VDM-SL exists. Also the proof tool does not yet deal with operations and statements. The main reason for this lack is the totally di erent way of proving in the imperative world: Due to side e ects [30], the whole history of state changes has to be considered. Traditional proof systems for statements use a pre-post strategy where a pre-predicate describes what is supposed to hold before execution of a speci c statement and a post-predicate describes what will hold after executing the statement [19, 5]. A few proof rules for VDM-SL statements, which are adapted for exception handling, can be found in [22]. Implicit operations can be treated as implicit functions, which means a satis ability proof obligation is generated to ensure consistency. However, explicit operations need another approach. 6.1 Generating Assertions The central idea in the POG to ensure the de nite consistency of VDM-SL operations is to generate assertions and include them into the speci cation. An assertion is a pre-predicate stating the property that must hold before a statement. Thus, in type checking operations the generated proof obligations are not proof rules but assertions. The abstract syntax for an assertion is: Assertion : : loc : Location prd : Sequent ; The assertion is composed of a sequent and a location. As in a PO above, a sequent states the needed property. The need for a sequent will be explained later. The location is needed due to the fact that an assertion is always related to a certain location in the speci cation. Location : :oper :Name stmt :N1 The Location is de ned by the operation name and the nth statement for which the assertion represents a pre-predicate. Nested statements are counted in the order of their appearance in the speci cation. Consider the following speci cation to calculate the average of a set of numbers: SmallNat = nat inv s == s < 256 Average: set of SmallNat ==> real Average (s) == ( dcl sum : SmallNat := 0; for all e in set s do ( if sum > 255 e then exit ; sum := sum + e ); return sum / card s ) As in traditional programming languages the numbers are restricted to a certain size (SmallNat). The operation takes the set of numbers as an argument and uses the local state sum and a loop to compute the result. In the loop an exception is raised if the sum is going to exceed its maximum. The loop statement is a good example of a construct for which it is impossible to generate a context as in the sections above. Therefore the POG generates and inserts the following assertions to ensure de nite consistency: Average: set of SmallNat ==> real Average (s) == ( --PO1: inv-SmallNat(0) dcl sum : SmallNat := 0; for all e in set s do ( if sum > 255 e then exit ; --PO2: inv-SmallNat(sum + e) sum := sum + e ); --PO3: card s <> 0 return sum / card s ) PO1 must hold before the rst declaration statement to ensure that the initialisation of sum will not violate the invariant. PO2 will be inserted before the assignment statement. It must be proved in order to ensure that the assignment will not exceed the maximum of sum. Finally, PO3 has to be included before the return statement. It can be seen as the obligatory pre-condition of the division expression. The return statement is de nitely not consistent, because PO3 is not provable. In the following we will change the speci cation to be consistent and will explain how we treat expressions in statements. 6.2 Expressions in Statements Like the return statement above, statements may include expressions. Therefore undecidability could occur in an expression. Consider the consistent version of the speci cation: Average2: set of SmallNat ==> real Average2 (s) == ( dcl sum : SmallNat := 0; for all e in set s do ( if sum > 255 e then exit ; sum := sum + e ); return if s <> fg then sum / card s else 0 ) Average2 returns zero if the set of numbers is the empty set by using an if expression. To be able to use the context in the expression the POG collects the context in expressions as in functions. The di erence from functions is that the POG type checking an operation generates a sequent assertion. The sequent notation is used to express the context of an expression as local context. The generated assertions for Average2 demonstrate this approach: Average2: set of SmallNat ==> real Average2 (s) == ( --PO1: inv-SmallNat(0) dcl sum : SmallNat := 0; for all e in set s do ( if sum > 255 e then exit ; --PO2: inv-SmallNat(sum) sum := sum + e ); --PO3: s <> fg ==> card s <> 0 return if s <> fg then sum / 0 else 0 ) Now PO3 states that under the assumption that s is unequal to the empty set, the cardinality of s is unequal to zero. Which is by de nition of cardinality true ( ==> is the turnstile `). 7 Relation to Previous Work Some similar work has been done before, but the speci ed proof obligation generator is the rst one for VDM-SL covering the advanced topics of pattern matching and the non-functional part (operations and states). The central idea in uencing this work comes from Flemming M. Damm, Hans Bruun, and Bo Stig Hansen [10, 11]. But also some other tools (methods) already generating proof obligations motivated this extension of the IFAD VDM-SL Toolbox with a proof obligation generator. RAISE: In the RAISE Speci cation Language [15, 27] an expressive notion of types is also used for type checking. As a separate facility, not part of type checking, proof obligations called \con dence conditions" may be generated. These rule out, e.g., dynamic type errors. PVS: PVS (Prototype Veri cation System) [25] is an environment for speci cation and veri cation consisting of a speci cation language, a parser, a type checker, and an interactive theorem prover. The type checker in PVS generates proof obligations called TCCs (Type Correctness Condition). However, PVS only supports (tagged) disjoint union types, which do not cause un-decidability like the non-disjoint unions in VDM-SL. The TCCs relate tosubtypes, partial operators and the termination of recursive functions.B-Method: The B-Toolkit [17] has a proof obligation generator, that can beinvoked from the \Main Environment". The POs are generated according tothe correctness criteria which are required to hold within the B-Method [1].Thus, for example the criteria requires that an Abstract Machine initialisa-tion must establish the invariant, and that each operation re-establishes theinvariant.Z/EVES: The Z/EVES system [28, 29], a Z front-end to the theorem proverEVES [9] provides domain checking for Z speci cations, which is the gen-eration of proof obligations to ensure that all functions and operators areapplied with parameters inside their domain. The same is done in our work,but Z does not have a type system as rich as VDM [18]. Our work covers awider area, e.g. union types and patterns. Thus, domain checking is a subsetof our consistency checks.SPARK: SPARK is an annotated subset of Ada, designed to eliminate ambi-guities and insecurities of the full Ada language [8]. The SPARK Examiner,a tool which checks conformance of a program to the rules of SPARK, alsogenerate POs called \veri cation conditions". Mandatory annotations in aprogram are used to generate these POs. However, SPARK does not al-low exceptions and overloading and has simpli ed scope and visibility rules.Unlike in our approach to operations, where annotations (assertions) aregenerated as proof obligations, in SPARK the annotations are added by theprogrammer in order to be able to generate POs [14].8 Concluding RemarksIn this paper we have presented an approach for automatic generation of proofobligations for VDM-SL.We have shown the general strategy and presented moredetails about the kinds of constructs for which this kind of proof obligationgeneration has not been done before. The approach presented has also beenformalised in terms of a VDM-SL speci cation for which a few extracts havebeen shown. From a tool point of view this work is an improvement of theexisting VDM-SL Toolbox. For a more detailed presentation of this work werefer the reader to [4].At present no work has been done on generating proof obligations for ter-mination of recursive functions. This work could also be extended by a closerintegration with the proof tool being developed. In particular we envisage a pos-sibility for the proof tool to automate the proof of type judgements by sendingit to the POG.The proof obligation generation approach presented here has several advan-tages: (1) A larger subset of speci cations can be formally checked according totheir internal consistency. (2) By using a proof tool many simple proof obliga-tions can be proved automatically. Thus, the link of automatic type checking and theorem proving extends the set of speci cations that can be checked auto-matically. (3) Proof obligations provide more information than an error message.The user who is familiar with the basics of logic reasoning, will often detect themissing parts in a speci cation. (4) By feeding the type errors as proof obliga-tions into a theorem prover, it leaves less for human examination, which reducesthe possibility of errors being disregarded by the user.We feel that the combination of a proof obligation generator as presentedhere and a proof support tool currently being developed will be a powerful com-bination. However, more work is needed to make a tighter integration betweensuch tools.AcknowledgementThe authors would like to thank their friends and colleagues for a careful readingof this article: Sten Agerholm, Brigitte Frohlich, Jeppe Nyl kke J rgensen, PaulMukherjee and Anne Berit Nielsen. Particularly Sten Agerholm has providedconsiderable input on the directions of the work reported in this paper. We aregrateful to the support of the Austrian Federal Ministry of Science, Research andthe Arts (Kurt Godel Scholarship) for Bernhard K. Aichernig's stay at IFAD.Finally, we want to thank Bernhard's professor, Peter Lucas, who made his staypossible.References1. J.-R. Abrial. The B Book { Assigning Programs to Meanings. Cambridge Univer-sity Press, August 1996.2. S. Agerholm and J. Frost. An Isabelle-based theorem prover for VDM-SL. InProceedings of the 10th International Conference on Theorem Proving in HigherOrder Logics (TPHOLs'97), LNCS. Springer-Verlag, August 1997.3. S. Agerholm and J. Frost. Towards an integrated CASE and theorem proving toolfor VDM-SL. FME'97, September 1997.4. Bernhard K. Aichernig. A Proof Obligation Generator for the IFAD VDM-SLToolbox. Master's thesis, Technical University Graz, Austria, March 1997.5. K. Apt. Ten Years of Hoare's Logic: A survey Part I. ACM-TOPLAS, 3(4):431{483, Oct 1981.6. Juan Bicarregui, John Fitzgerald, Peter Lindsay, Richard Moore, and BrianRitchie. Proof in VDM: A Practitioner's Guide. FACIT. Springer-Verlag, 1994.ISBN 3-540-19813-X.7. Hans Bruun, Flemming Damm, and Bo Stig Hansen. An Approach to the StaticSemantics of VDM-SL. In VDM '91: Formal Software Development Methods, pages220{253. VDM Europe, Springer-Verlag, October 1991.8. Bernard Carre, William Marsh, and Jon Garnsworthy. SPARK: A Safety-RelatedAda Subset. In Ada UK Conference, pages 1{19, August 22 1992.9. Dan Craigen, Sentot Kromodimoeljo, Irwin Meisels, Bill Pase, and Mark Saaltink.Eves: An overview. In S. Prehn and W.J. Toetenel, editors, VDM'91 { FormalSoftware Development Methods, pages 389{405. Springer-Verlag, October 1991. 10. Flemming Damm, Hans Bruun, and Bo Stig Hansen. On Type Checking in VDMand Related Consistency Issues. In VDM '91: Formal Software Development Meth-ods, pages 45{62. VDM Europe, Springer-Verlag, October 1991.11. Flemming M. Damm and Bo Stig Hansen. Generation of Proof Obligations forType Consistency. Technical Report 1993-123, Department of Computer Science,Technical University of Denmark, December 1993.12. John Dawes. The VDM-SL Reference Guide. Pitman, 1991. ISBN 0-273-03151-1.13. Rene Elmstr m, Peter Gorm Larsen, and Poul B gh Lassen. The IFAD VDM-SLToolbox: A Practical Approach to Formal Speci cations. ACM Sigplan Notices,29(9):77{80, September 1994.14. Jon Garnsworthy, Ian O`Neill, and Bernhard Carre. Automatic Proof of Absenceof Run-time Errors. In Ada UK Conference. London Docklands, October 1993.15. The RAISE Language Group. The RAISE Speci cation Language. The BCS Prac-titioners Series. Prentice-Hall, 1992.16. The VDM Tool Group. User Manual for the IFAD VDM-SL Toolbox. Technicalreport, IFAD, May 1996. IFAD-VDM-4.17. Howard Haughton. Speci cation in B: An Introduction Using the B Toolkit. WorldScienti c Publishing, 1996.18. I.J. Hayes, C.B. Jones, and J.E. Nicholls. Understanding the Di erences BetweenVDM and Z. FACS Europe, pages 7{30, Autumn 1993.19. C.A.R. Hoare. An Axiomatic Basis for Computer Programming. Communicationsof teh ACM, 12(10):576{581, October 1969.20. Cli Jones, Kevin Jones, Peter Linsay, and Richard Moore, editors. mural: AFormal Development Support System. Springer-Verlag, 1991. ISBN 3-540-19651-X.21. Cli B. Jones. Systematic Software Development Using VDM. Prentice-Hall Inter-national, Englewood Cli s, New Jersey, second edition, 1990. ISBN 0-13-880733-7.22. Peter Gorm Larsen. Towards Proof Rules for VDM-SL. PhD thesis, Technical Uni-versity of Denmark, Department of Computer Science, March 1995. ID-TR:1995-160.23. P.G. Larsen, B. S. Hansen, H. Brunn, N. Plat, H. Toetenel, D. J. Andrews,J. Dawes, G. Parkin, and et. al. Information Technology { Programming lan-guages, their environments and system software interfaces { Vienna DevelopmentMethod { Speci cation Language { Part 1: Base language, ISO/IEC 13817-1, De-cember 1996.24. Paul Mukherjee. Computer-aided Validation of Formal Speci cations. SoftwareEngineering Journal, pages 133{140, July 1995.25. Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. FormalVeri cation for Fault-Tolerant Architectures: Some Lessons Learned. In J.C.P.Woodcock and P.G. Larsen, editors, FME'93: Industrial-Strength Formal Methods,pages 482{501. Formal Methods Europe, Springer-Verlag, April 1993. LectureNotes in Computer Science 670.26. Nico Plat and Peter Gorm Larsen. An Overview of the ISO/VDM-SL Standard.Sigplan Notices, 27(8):76{82, August 1992.27. The RAISE Method Group. The RAISE Development Method. The BCS Practi-tioners Series. Prentice-Hall International, 1995.28. Mark Saaltink. Z and EVES. In J.E. Nicholls, editor, Z User Workshop, York1991, pages 223{242. Springer-Verlag, 1992. Workshops in Computing.29. Mark Saaltink. The Z/EVES system. Technical report, ORA Canada, September1995. 30. R.D. Tennent. Principles of Programming Languages. Prentice-Hall International,Englewood Cli s, New Jersey 07632, 1981.31. The VDM Tool Group. The IFAD VDM-SL Language. Technical report, IFAD,May 1996. IFAD-VDM-1.This article was typeset using theLATEX macro package with the LLNCS2E class.